承接著上一則 post 提到 cucumber 的 BDD 開發方式: https://www.facebook.com/…/p.468570883317…/468570883317535/…
之前好友 @Steven Mak 分享了一篇網路上不錯的文章：〝Now I’ll really use test driven development to write device driver code〞
網址：http://www.renaissancesoftware.net/blog/archives/8
我簡單整理了一下在這幾年中，建議開發團隊的開發流程，剛好與這整篇文章的脈絡，以及 cucumber 的開發流程圖做個呼應：
1. 把 user story 整理好到 feature 上：目的用來釐清自己的思緒，穩定心情，知道自己接下來要做的事情，對使用者到底有什麼樣的幫助，以及自己接下來到底要開發什麼樣的功能。如果無法簡短的說明出來，就代表「不容易與其他人溝通」。
2. 把各個 test cases 列出來形成 scenarios：什麼樣不同的 input ，如果背後有什麼樣的資料流，則我們預期最後的結果為何。目的用來跟使用者/PO 確認需求的 scenario 是否應當如此運作，有沒有漏掉這個需求代表性的 scenarios？（RA，可透過需求工程來輔助）
3. 目前還沒有 production code，我們也得到了一到多個紅燈，這些紅燈是使用者認定要做的事情 (the right thing), 但目前還沒完成。
4. 根據 domain/business rule/business flow ，試圖滿足這個 user story 的各個 scenarios，代表滿足這一整個使用者需求，代表就可以帶給使用者對應的 benefit。 值得注意的是，這個 business rule/flow, 不一定全然是 user/PO 所提出的，而應該是 domain expert 引導整個 team, 包含對 domain 有興趣的 PO，所討論跟擬訂出來的商業邏輯。也就是 RA+SA 。
5. 根據 business flow 寫出 context 的抽象流程（這篇文章中所謂的 pseduo code），這時候可能會得到一堆 private function，這些 private function 基本上就是 flowchart 上的 process element，最後 developer 只要針對 private function 的各個意義去填補即可，期望最後獲得綠燈。
6. 得到綠燈之後，快速地檢查一遍自己的 production code 是否存在著壞味道，如果有，進行重構。快速地透過靜態程式碼分析工具，掃一次這一次新增的 production code 在整個 project 中，有沒有與其他物件或模組之間存在著壞味道，如果有，進行重構。
7. 重構完成後， checkin 程式碼，因為完成了一個 user story ，這是維持節奏中一個不錯的斷點。checkin 完程式碼，留意有沒有 CI 發出來的品質趨勢下降的通知，或是直接是去 CI 看這次 checkin/build 的 dashboard, 檢查這次異動的 production code 對整個 project 的品質來說，相對是提升還是下降，如果是下降，再進行重構。
#BDD #TDD #cucumber
套句好朋友 Dino Wang 的話：「透過BDD，覺得TDD變溫柔了」
這張圖是使用 cucumber 來進行 BDD 的完整示意圖，可以看到所有的程式碼都是從 user requirements 當出發點。
淺藍色的部分，則是使用自然語言(domain specific language)描述的 user story 與 scenarios。
→ 不管是誰都看得懂的表達方式，涵蓋了 why, who, what 。
左邊淡紅色的部分，則是 steps 的內容，也就是 scenario how 的部分，說明「如何使用 product 來完成 scenarios （所代表的需求）。所以，測試程式就只要把 steps 的肉填滿即可，執行測試程式的骨頭跟流程，都是在 cucumber gherkin style 的 scenarios 上。
→ 只需 focus 在 step 要填入什麼樣的測試程式，要理解 context 只需要看自然語言的 scenarios 即可。
有了可以執行的測試程式，還沒有 production code，自然就會得到 TDD 的第一個紅燈。也就是右下角的TDD區塊。接著只需要順其自然的依照 TDD 的三個步驟：紅燈、綠燈、重構，就可以完成使用者的需求。
→如果你的 TDD 在實務上顯得彆扭，沒頭沒尾，那就代表只有片段，還有前面的技巧需要補齊。
如此一氣呵成，從需求→scenearios(accetpance criteria)→測試程式→production code→自動產生文件，一點都沒浪費卻又一鼓作氣的完整，就是最美妙的地方。
--
若對這樣的開發方式有興趣想瞭解或學習的朋友，可以參考我在 skilltree 上的課程介紹，以及其他上過課學員的心得：http://skilltree.my/events/mbh
Search